home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d7 / hotk_z60.arc / JMODEM.DOC < prev    next >
Text File  |  1989-03-31  |  28KB  |  757 lines
  1.  
  2.                                   J M O D E M
  3.                               File Transfer System
  4.                                  Compliments of
  5.                                Richard B. Johnson
  6.                                 PROGRAM EXCHANGE
  7.                                  (719) 548-0208
  8.                                 October 4, 1988
  9.  
  10.           General:
  11.           First Let me get this over with.
  12.           MS-DOS is a registered trademark of Microsoft Corporation
  13.           IBM, IBM-PC, IBM-XT, AT, are registered trademarks of Inter-
  14.           national Business Machines, Inc. WILDCAT! is a trademark of
  15.           Mustang Software. XMODEM is a public-domain file-transfer
  16.           protocol developed by Ward Christensen.
  17.  
  18.           JMODEM is released into the public domain. As with most
  19.           public-domain protocols, you are advised that there is no
  20.           implied warranty of any kind. The source-code is provided so
  21.           that you may determine for yourself if this program may
  22.           serve a useful purpose. It is written in Microsoft MASM
  23.           Assembly-language using good standards of engineering prac-
  24.           tice. It does not use any strange or "undocumented" func-
  25.           tions of the MS-DOS operating system.
  26.  
  27.                 PLEASE UPLOAD THIS FILE (The ARC file) to as many
  28.                 BBS systems as you can so that it gets installed
  29.                 all around the country.
  30.  
  31.           Introduction:
  32.           JMODEM is a new file-transfer protocol developed to be used
  33.           as an "external protocol" on BBS systems and personal com-
  34.           puters using the IBM-PC/AT/XT structure and the MS-DOS oper-
  35.           ating system.
  36.  
  37.           This file-transfer system features:
  38.  
  39.                 o       16-bit CRC for verification
  40.                 o       File size is exactly maintained
  41.                 o       Data compression.
  42.                 o       Rapid host/remote synchronization.
  43.                 o       Variable-length transmission blocks which,
  44.                         if there are few errors, increase to 8192
  45.                         data-bytes in length.
  46.                 o       Flow control (automatic)
  47.                 o       Hangup protection
  48.                 o       Aborted files are saved
  49.                 o       Files being overwritten are renamed to
  50.                         ".OLD", rather than deleted.
  51.                 o       COM1 - COM4 support.
  52.                 o       Interrupt on received characters allows data
  53.                         to be received while the previous block is
  54.                         being written to disk. This provides almost
  55.                         continuous data transmission without long
  56.                         waits between blocks.
  57.  
  58.  
  59.  
  60.  
  61.  
  62.                                      - 1 -
  63.           
  64.                                                JMODEM Protocol  Page 2
  65.  
  66.  
  67.           JMODEM is not for everyone! It does not have any pretty
  68.           screens to dazzle the user. It is designed to maximize the
  69.           amount of data that can be transferred in a given time (and
  70.           reduce telephone cost). It does this by sending very long
  71.           blocks of data and encoding (compressing) the data wherever
  72.           possible. Since long blocks of data are subject to many
  73.           transmission errors, a 16 bit CRC is used to determine the
  74.           data integrity. As many as ten retries are made if the data
  75.           is not correctly received. If you have a noisy telephone
  76.           circuit, you will find that JMODEM will abort more often
  77.           than the XMODEM protocol which sends very short blocks. A
  78.           future version that will be downward-compatible with the ex-
  79.           isting version is being developed that will do "heroic"
  80.           retries and will even go down to a 16-byte block-lengths if
  81.           that's what is necessary to get the data transferred.
  82.  
  83.           Once synchronization between the remote computer and the
  84.           host are established, JMODEM paints a status block on the
  85.           screen that shows how the file transfer is going. The status
  86.           screen shows the block being transmitted (or the last re-
  87.           ceived), the length of the block, and the total bytes having
  88.           been transmitted (or received). A special synchronization
  89.           routine is used so that the first block is not thrown away
  90.           as happens so often in XMODEM type routines. During the syn-
  91.           chronization routine, where the host is waiting for the user
  92.           to enter the proper file parameters (a 30 second wait).  You
  93.           can abort immediately by sending a control X (^X). After ac-
  94.           tual file transfer begins, ie. when you see the status win-
  95.           dow on the screen, no input from the keyboard is possible.
  96.           You send a control BREAK to abort the transmission (or ^C).
  97.           In this case, the program will abort after the block being
  98.           sent/received is complete. This could take 15 or more sec-
  99.           onds with long blocks so be patient.
  100.  
  101.           In the event that carrier is lost (the user disconnected),
  102.           the file-transfer program will also abort. This, too, could
  103.           take as long as 15 seconds.
  104.  
  105.           How it works:
  106.           The block size starts out at 512 bytes (or the actual bytes
  107.           in the file -- whichever is less). To this is added a 6-byte
  108.           overhead. If the block transfer occurred without any
  109.           retries, the block length is increased by 512 bytes to 1024
  110.           bytes. As long as the transmission was successful without
  111.           incurring any re-tries, the block-length increases to a max-
  112.           imum of 8192 bytes. There is still the same 6-byte overhead
  113.           so the maximum block length will actually be 8198 bytes. Any
  114.           time there are retries, the block length (on the next new
  115.           string) is decreased by 512 bytes. The string-length is
  116.           never reduced to less than 512 bytes due to errors. When the
  117.           last bytes are read from the file, the block length may be
  118.           as little as 7 bytes (one data byte, plus the 6 byte over-
  119.           head). The file size as received will be exactly the file
  120.  
  121.  
  122.  
  123.  
  124.  
  125.                                      - 2 -
  126.           
  127.                                                JMODEM Protocol  Page 3
  128.  
  129.           size as transmitted. XMODEM will "round-up" the file size to
  130.           the next higher block. This means that MS-DOS's COMP (com-
  131.           pare) will always fail when you attempt to check files that
  132.           have been sent by XMODEM and many other protocols.
  133.  
  134.           When the file is read, an attempt is made to compress the
  135.           data using the well-known RLL process where multiple bytes
  136.           are compressed into a 4-byte statement.
  137.  
  138.           For instance a string that looks like this (hex):
  139.                 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0
  140.           Gets compressed into this:
  141.                 BB 0F 00 A0
  142.                  |  |  |  |__________ Byte to repeat
  143.                  |  |  |_____________ High byte of repeat length
  144.                  |  |________________ Low byte of repeat length
  145.                  |___________________ Sentinel Byte
  146.  
  147.           The sentinel-byte (BBH), when encountered in a data stream
  148.           will get expanded to four bytes. Therefore, it is possible
  149.           for the "compressed" data string to actually be longer than
  150.           the original. If this occurs, the original string is sent
  151.           rather than the longer encoded one. Since the kind of data
  152.           sent can be different from block-to-block, it is necessary
  153.           to send a control-byte along with the data so the receiver
  154.           had determine how to operate on the data.
  155.  
  156.           This is the control structure:
  157.  
  158.           00 02 00 0B 01 02 03 04 05 06 07 08 09 0A .... 0A EA
  159.            |  |  |  |  |                                 |  |_ CRC
  160.            |  |  |  |  |                                 |____ CRC
  161.            |  |  |  |  |______________________________________ data
  162.            |  |  |  |_________________________________________ rec.
  163.            |  |  |____________________________________________ control
  164.            |  |_______________________________________________ length
  165.            |__________________________________________________ Length
  166.  
  167.           Two bytes are used for the string length and two bytes are
  168.           used for the CRC. As is standard in memory, the high-byte
  169.           looks "to people using DEBUG" swapped with the low byte. The
  170.           data is transmitted exactly as the memory image.
  171.  
  172.           The length (a word) begins the string so the receiver may
  173.           know exactly how may bytes to receive.
  174.  
  175.           The control byte is bit-mapped to 8 possibilities. The ones
  176.           most important are:
  177.  
  178.                         NORMAL DATA
  179.                         COMPRESSED DATA
  180.                         END OF FILE
  181.                         ABORT
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.                                      - 3 -
  189.           
  190.                                                JMODEM Protocol  Page 4
  191.  
  192.           This is now the receiver "knows" what to do with the data.
  193.  
  194.           The CRC is generated using this polynomial:
  195.  
  196.           X =  X + X^(2(n-mod 7).......  Where n = t(n-1)
  197.                                          And t = string length
  198.  
  199.           It has the advantage of simplicity in assembly-language pro-
  200.           gramming and will detect errors with a probability of about
  201.           one undetected error in 2^132 (which is a very large num-
  202.           ber). It does not correct errors so its not important to use
  203.           some "standard" function to generate the CRC.
  204.  
  205.           Support for COM3 and COM4 have been added on revision level
  206.           V1.05 . Note that the standards for port locations are de-
  207.           facto standards only and may not be the ports actually used
  208.           in your computer. Please modify the communications port
  209.           structures at the beginning of the assembly-language program
  210.           to match your system parameters if they are different. The
  211.           modifications should be done to the STRUCTURES, not to the
  212.           EQUATES!
  213.  
  214.           Revision level V1.09 brings musical exit status. If the file
  215.           transfer was successful, the computer plays "victory". If
  216.           the file transfer was aborted, the computer plays "retreat".
  217.           Since the BBS SysOp is unlikely to want his computer to play
  218.           bugle-calls well into the evening, the user has the option
  219.           of turning the music off. This is done by setting an en-
  220.           vironment variable string:
  221.  
  222.           SET JMODEM=SHUTUP
  223.  
  224.                 ... Will accomplish the desired result.
  225.           Usage:
  226.           This program uses parameters on the command line.
  227.  
  228.           JMODEM S <filename.typ>       ( Sends a file to COM1:)
  229.           JMODEM R <filename.typ>       ( Receives a file from COM1:)
  230.           JMODEM S1 <filename.typ>      ( Sends a file to COM1:)
  231.           JMODEM R1 <filename.typ>      ( Receives a file from COM1:)
  232.           JMODEM S2 <filename.typ>      ( Sends a file to COM2:)
  233.           JMODEM R2 <filename.typ>      ( Receives a file from COM2:)
  234.  
  235.           After version 1.05, JMODEM supported communications adapter
  236.           ports 1 through 4.
  237.  
  238.           In a batch file, <filename.typ> may be a substitution
  239.           character.
  240.           JMODEM S2 %1                  ( Sends a file to COM2:)
  241.           JMODEM R2 %1                  ( Receives a file from COM2:)
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.                                      - 4 -
  252.           
  253.                                                JMODEM Protocol  Page 5
  254.  
  255.                       Setting up a Communications Program
  256.                         External File-Transfer Protocol.
  257.  
  258.           On my system, TELIX resides in the C:\TELIX directory. A
  259.           copy of JMODEM.COM is also in that directory. TELIX passes
  260.           the filename as the %3 parameter. Therefore the contents of
  261.           JUP.BAT is:
  262.  
  263.                         C:\TELIX\JMODEM S1 %3
  264.  
  265.           The contents of JDOWN.BAT are:
  266.  
  267.                         C:\TELIX\JMODEM R1 %3
  268.  
  269.           If I wished to receive in the "batch" mode, I could make a
  270.           file like this. Notice that some communications programs do
  271.           not allow multiple file names. Note that the comments "!"
  272.           are NOT ALLOWED in a DOS batch file.
  273.  
  274.                         :DO_LOOP                   ! Return here
  275.                         IF "%3" == "" GOTO DONE    ! More parameters?
  276.                         C:\TELIX\JMODEM R1 %3      ! Execute JMODEM
  277.                         IF ERRORLEVEL 1 GOTO DONE  ! Abort on error
  278.                         SHIFT                      ! %4 becomes %3
  279.                         GOTO DO_LOOP               ! Continue
  280.                         :DONE                      ! Exit batch file
  281.  
  282.           If you do not know what "%" parameters are used to pass the
  283.           file name, all you have to do is make a "dummy" batch file
  284.           that contains the following:
  285.  
  286.                         @ECHO OFF
  287.                         ECHO %1
  288.                         ECHO %2
  289.                         ECHO %3
  290.                         ECHO %4
  291.                         ECHO %5
  292.                         PAUSE
  293.  
  294.           When this is executed, you will see something like this:
  295.  
  296.                 1200
  297.                 1
  298.                 FILENAME.TYP
  299.                 ECHO is off
  300.                 ECHO is off
  301.                 Strike a key when ready . . .
  302.  
  303.           The first line contains "1200" which is the baud rate. This
  304.           means that the %1 parameter contains the baud rate.
  305.  
  306.           The second line contains "1" which is the communications
  307.           adapter port being used. This means that the port is being
  308.           passed as the %2 parameter.
  309.  
  310.  
  311.  
  312.  
  313.  
  314.                                      - 5 -
  315.           
  316.                                                JMODEM Protocol  Page 6
  317.  
  318.  
  319.           The third line contains "FILENAME.TYP" which is the file
  320.           name. This means that the file name is being passed as the
  321.           %3 parameter.
  322.  
  323.           The fourth and fifth lines contain nothing to echo so DOS
  324.           replies the current state of the echo function which is
  325.           "off".
  326.  
  327.           PCPLUS handles the file name passing a little bit different.
  328.           If I execute the same "dummy" batch file from the PCPLUS
  329.           directory, the response is:
  330.  
  331.                 FILENAME.TYP
  332.                 ECHO is off
  333.                 ECHO is off
  334.                 ECHO is off
  335.                 ECHO is off
  336.                 Strike a key when ready . . .
  337.  
  338.           This shows us that PCPLUS passes the file name as the first
  339.           parameter and there are no other parameters. However, If I
  340.           put more parameters on the command line within PCPLUS, they
  341.           will get sent to the batch file. The response is:
  342.  
  343.                 FILENAME.001
  344.                 FILENAME.002
  345.                 FILENAME.003
  346.                 FILENAME.
  347.                 ECHO is off
  348.                 Strike a key when ready . . .
  349.  
  350.           Therefore PCPLUS allows up to four file names to be passed
  351.           providing there's room on the command line.
  352.  
  353.           Notice that these two communications programs check the de-
  354.           fault directory for the external protocol batch file FIRST!
  355.           Therefore you must make certain that there are no other
  356.           similarly-named batch files in the current directory or
  357.           within the current path. Failure to do so will cause the im-
  358.           proper execution of the wrong batch file. Lets say that the
  359.           path was "C:\DOS;C:\TOOLS;C:\PCPLUS;C:\TELIX;C:\QMODEM". If
  360.           you named all your JMODEM external protocol batch files with
  361.           the same name, and you were attempting to use an external
  362.           file transfer protocol from QMODEM, the batch file designed
  363.           to operate with PCPLUS would be the first one "found" and
  364.           executed since the search-path will search the \PCPLUS
  365.           directory before the \QMODEM directory. You prevent the ex-
  366.           ecution of the incorrect batch file by calling them slightly
  367.           different names.
  368.  
  369.           When setting up external protocols, remember to configure
  370.           the communications program so that it prompts you for the
  371.           file names. Unlike some protocols, JMODEM does not transfer
  372.  
  373.  
  374.  
  375.  
  376.  
  377.                                      - 6 -
  378.           
  379.                                                JMODEM Protocol  Page 7
  380.  
  381.           the file name. You can use any file name that you wish. You
  382.           must pass the file name to JMODEM since it must know the
  383.           name of the file being transmitted or received. There are no
  384.           defaults.
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.                                      - 7 -
  441.           
  442.                                                JMODEM Protocol  Page 8
  443.  
  444.                             Setting up a BBS System
  445.                         External File-Transfer Protocol.
  446.  
  447.  
  448.           If you are running a WILDCAT! bulletin board, the external
  449.           protocol files can be set up like this:
  450.  
  451.                         (JUP.BAT)
  452.                         CD D:\WILDCAT\PROTOCOL
  453.                         IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
  454.                         JMODEM R1 %3
  455.                         IF ERRORLEVEL 1 GOTO END
  456.                         COPY %3 %4
  457.                         :END
  458.                         DEL %3
  459.  
  460.                         (JDOWN.BAT)
  461.                         CD D:\WILDCAT\PROTOCOL
  462.                         IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
  463.                         JMODEM S1 %3
  464.                         IF ERRORLEVEL 1 GOTO BAD
  465.                         GOTO END
  466.                         :BAD
  467.                         COPY ALL.OK TRANSFER.BAD
  468.                         :END
  469.  
  470.           There are many variations available. Since WILDCAT! supports
  471.           batch-mode downloading, you could set up the batch file like
  472.           this:
  473.  
  474.                         (JDOWN.BAT)
  475.                         CD D:\WILDCAT\PROTOCOL
  476.                         IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
  477.                         :DO_LOOP
  478.                         IF "%3" == "" GOTO END
  479.                         JMODEM S1 %3
  480.                         IF ERRORLEVEL 1 GOTO BAD
  481.                         SHIFT
  482.                         GOTO DO_LOOP
  483.                         :BAD
  484.                         COPY ALL.OK TRANSFER.BAD
  485.                         :END
  486.  
  487.           WILDCAT! checks the \PROTOCOL directory to see if the file
  488.           TRANSFER.BAD has been created. If it exists, it announces
  489.           that the file transfer has failed. It also announces "Error
  490.           with external protocol .. ". It does this when, in fact,
  491.           WILDCAT!  has made an error itself. In many cases WILDCAT!
  492.           will "find" the file TRANSFER.BAD when it DOES NOT EXIST! In
  493.           spite of this bug, WILDCAT! is one of the most reliable BBS
  494.           systems supporting external protocols.
  495.  
  496.           When setting up batch files remember that there is also a
  497.           bug in all DOS versions. The "IF ERRORLEVEL " statement does
  498.  
  499.  
  500.  
  501.  
  502.  
  503.                                      - 8 -
  504.           
  505.                                                JMODEM Protocol  Page 9
  506.  
  507.           NOT test the actual value of ERRORLEVEL! Instead it checks
  508.           to see if the returned value is EQUAL or GREATER than the
  509.           tested value. If you were to put the statement:
  510.  
  511.                         IF ERRORLEVEL 0 GOTO GOOD
  512.  
  513.           .... in a batch file, the execution would ALWAYS branch to
  514.           label "GOOD" regardless of the actual ERRORLEVEL returned!
  515.           More about bugs when we get to the "BAD BBS" section towards
  516.           the end.
  517.  
  518.           JMODEM does not require any information about handshaking.
  519.           It will look at the modem port and figure out for itself
  520.           what to do.
  521.  
  522.           In the event that the modem carrier is lost, JMODEM will
  523.           abort. Since JMODEM only checks the modem port occasionally,
  524.           it may take several seconds to abort when the carrier is
  525.           lost. It is impossible for a user to get at the DOS level
  526.           through JMODEM. Do NOT use the CTTY command in the external
  527.           protocol batch files. JMODEM returns ERRORLEVEL 1 if there
  528.           was any error in transmission or reception. It returns ER-
  529.           RORLEVEL 0 (no error) otherwise. It does not delete files
  530.           that have been partially received although it properly
  531.           closes them. The system operator can arrange the batch files
  532.           to delete them if required.
  533.  
  534.           When JMODEM attempts to create a file that already exists it
  535.           can't ask the user if the old one should be deleted since
  536.           the user is probably not in a terminal program at the time.
  537.           Therefore, JMODEM renames the other file to <filename.OLD>
  538.           and creates the new file. In the event that <filaname.OLD>
  539.           exists, it is deleted before the rename operation occurs.
  540.  
  541.           If you don't know what parameters are being sent to external
  542.           protocols, you can make a dummy batch file to check them
  543.           using the DOS's echo command just as explained in the user
  544.           interface previous to this "BBS" section. You can't see the
  545.           parameters being echoed from a remote terminal. You must be
  546.           present at the BBS board terminal to test those parameters
  547.           unless you modify the dummy command file like this:
  548.  
  549.                         @ECHO OFF
  550.                         ECHO %1>COM1
  551.                         ECHO %2>COM1
  552.                         ECHO %3>COM1
  553.                         ECHO %4>COM1
  554.                         ECHO %5>COM1
  555.  
  556.           If you find that your system passes the file name as %3,
  557.           your "upload" (receive) batch file would contain this:
  558.  
  559.                         JMODEM R1 %3
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.                                      - 9 -
  567.           
  568.                                               JMODEM Protocol  Page 10
  569.  
  570.           Your "download" (send) batch file would contain this:
  571.  
  572.                         JMODEM S1 %3
  573.  
  574.           In these examples, it is assumed that you are using communi-
  575.           cations adapter port "1".
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.                                      - 10 -
  630.           
  631.                                               JMODEM Protocol  Page 11
  632.  
  633.                                   The BAD BBS
  634.                                     Problem.
  635.  
  636.           Believe it or not, there are several very fine running BBS
  637.           systems in use that do not properly handle external proto-
  638.           cols. MS-DOS provides the proper mechanism for loading and
  639.           executing "child" programs from within the "parent" pro-
  640.           grams. This is function 4BH of the "DOS" INT 21H DOS inter-
  641.           face. Instead of using this function, these poorly-behaved
  642.           programs perform the external file-transfer protocol in the
  643.           following (or similar) manner:
  644.  
  645.                 (1) Make a DOS call to find the file-size of the ex-
  646.           ternal file-transfer protocol.
  647.  
  648.                 (2) Free up an array of memory from "string-space"
  649.           within the program that is large enough to copy the external
  650.           file transfer contents into it. As assumption about the
  651.           data-space required by the external file transfer program is
  652.           made based upon the "block-size" information that has been
  653.           entered during configuration.
  654.  
  655.                 (3) Loads the file into string-space memory.
  656.  
  657.                 (4) If its an ".EXE" file, ignore the header.
  658.  
  659.                 (5) CALL the first byte of code!
  660.  
  661.                 If JMODEM is run in this environment, it WILL crash
  662.           the system. JMODEM assumes that it has been placed in memory
  663.           by MS-DOS and that an entire segment (64k) is available to
  664.           run. JMODEM uses two buffers that are almost 32k in length!
  665.           One of the buffers is used to support data compression and
  666.           expansion. The other is used for the interrupt buffer.
  667.  
  668.           If you have such a BBS system and you wish to run JMODEM,
  669.           you can make a simple modification to the source-code, and
  670.           re-compile to produce a version which is a bit slower to in-
  671.           itialize and exit, but is guaranteed to leave all memory and
  672.           registers EXACTLY as they were when JMODEM got control. This
  673.           is done by saving and restoring all registers. Additionally,
  674.           any data space that will be modified is copied to a file
  675.           called VIRTUAL.MEM, then restored from that file just before
  676.           JMODEM exits.
  677.  
  678.           You modify the source-code by finding the "BAD_BBS" equate
  679.           near the beginning of the file. This is normally set to
  680.           "FALSE". You set this to "TRUE". Then you recompile in the
  681.           following manner:
  682.  
  683.                 MASM JMODEM;
  684.                 LINK JMODEM;
  685.                 EXE2BIN JMODEM.EXE JMODEM.COM
  686.                 DEL JMODEM.EXE
  687.  
  688.  
  689.  
  690.  
  691.  
  692.                                      - 11 -
  693.           
  694.                                               JMODEM Protocol  Page 12
  695.  
  696.  
  697.           Do NOT attempt to execute the ".EXE" version. You must
  698.           change JMODEM to a ".COM" file. If you do not have
  699.           EXE2BIN.COM to make the change, you can use DOS's DEBUG to
  700.           do the same thing. You do it this way:
  701.  
  702.           F:\DEV> debug jmodem.exe      ; DOS command line
  703.  
  704.           -rcx                          ; Examine CX register
  705.  
  706.           CX 1239                       ; Debug says the size was 1239
  707.           :
  708.  
  709.           -h 1239,100                   ; Calculate 1239H - 100H
  710.  
  711.           1339  1139                    ; Sum = 1339H, dif = 1139H
  712.           -rcx                          ; Examine register again
  713.  
  714.           CX 1239                       ; Is 1239H
  715.           :1139                         ; Change to 1139H
  716.                                         ; .. subtract 100H
  717.           -njmodem.com                  ; Name new SAVE file name
  718.  
  719.           -w                            ; Write to file
  720.  
  721.           Writing 1139 bytes            ; Debug prompts
  722.           -q                            ; Exit
  723.  
  724.           F:\DEV>                       ; Back to DOS
  725.  
  726.           When you use this version of JMODEM, it will take a little
  727.           while longer to load and exit because it must write a 64k
  728.           block of memory to a file and read / delete in upon exit.
  729.  
  730.           If you have problems using JMODEM with your system, you can
  731.           call the PROGRAM EXCHANGE and leave a message You can also
  732.           test your communications program's external file-transfer
  733.           protocols by transferring files (hopefully uploading) to the
  734.           PROGRAM EXCHANGE. Currently there are hundreds of boards
  735.           that are using this protocol and the number is growing every
  736.           day. Most problems encountered are found to be caused by in-
  737.           correct file names being sent to JMODEM (the wrong "%" pa-
  738.           rameters). A simple batch file to test these parameters will
  739.           go a long way towards solving the problems.
  740.  
  741.                                 Richard B. Johnson
  742.                                 PROGRAM EXCHANGE
  743.                                 (719) 548-0208
  744.                                 4750 Rusina Road # 106
  745.                                 Colorado Springs, CO
  746.                                 80907
  747.  
  748.           - Finis -
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.                                      - 12 -
  756.           
  757.